OSS-Fuzz: Move fuzzer to upstream repository - #6203

Thanks for proposing this! Keeping the fuzzers alongside the code they exercise would let us review and update both together.

My concern is that this PR adds the source file without integrating it into our build or tests. Changes in either pybind11 or the OSS-Fuzz environment could then break the harness while all pybind11 CI checks remain green. Before we take ownership of this code, I’d like us to establish a sustainable way to build, exercise, and maintain it.

I don't have experience working with fuzzers, so the requests below were mostly written by codex GPT-6.1-Sol ultra, with small manual edits:

Could you please add the following?

1. A supported build target for the harness. Ideally, our tests and OSS-Fuzz would use the same build rule. Making this optional and enabling it in one suitable CI configuration would be sufficient; we don’t need LLVM dependencies throughout our test matrix.

2. A small checked-in corpus and an automated replay test. This should exercise the actual fuzz callback, with inputs covering both successful operations and expected Python exceptions. There should be at least one CI job.

3. An automated check of the OSS-Fuzz integration. CIFuzz looks like a suitable option for building and briefly running the fuzzers on PRs. Another approach would also be welcome if it checks compatibility with the actual OSS-Fuzz build environment.

I’d also appreciate an explanation of which pybind11 behavior this harness is intended to exercise, particularly because it involves py::exec. When a failure is reported, we’ll need to reproduce it locally, understand the operations involved, and reduce it to a focused regression test. Could you document that workflow? Would fixed Python snippets with fuzzed arguments, or a selection of explicit binding and conversion operations, make failures easier to investigate? I’m open to your advice on the approach; I’d like us to establish that the harness provides useful coverage and that maintaining and debugging it will be practical for pybind11 contributors.